Various system architectures support the use of specially-protected, “trusted” software modules, such as, for example, to perform specific tamper-resistant software, or systems using technology to run protected applications sensitive activities, even in the presence of other hostile software in the system. Some of these trusted software modules require equivalently “trustable” protected access to peripheral devices. In general, such access requires that the trusted software be able to: identify the device's capabilities and/or specific identity, and then establish a secure session with the device to permit the exchange of data that cannot be snooped or spoofed by other software in the system.
The traditional method of both identifying the device and simultaneously establishing the encrypted session is to use a one-side authenticated Diffie-Hellman (DH) key exchange process. In this process, a device is assigned a unique DH public/private key pair. The device holds and protects the private key, while the public key, along with authenticating certificates, may be released to the software. During the DH key exchange process, the software obtains the certificate of the device and verifies the devices' certificate. The software then generates a random ephemeral DH public/private key pair and sends the ephemeral public key to the device. The device computes a shared secret using the device private key and the software ephemeral public key. The software computes a shared secret using the device public key and the software ephemeral private key. Following the Diffie Hellman protocol, the software and the device will compute the same shared secret. The software knows that the shared secret is known only to a trusted device because of the certificate on the public key of the device. The shared secret can now be used to encrypt and authenticate messages between the software and the device.
However, because this authentication process uses conventional private/private key pairs, the device discloses a unique and provable identity (i.e., its public key) as part of the authentication process. Any software that can get the device to engage in a key exchange with its private key can prove that this specific, unique device key is present in a system. Given that devices rarely migrate between systems, this also represents a provable unique system identity. Furthermore, the device's public key itself represents a constant unique value; effectively a permanent “cookie”. In some circles, these characteristics will be construed as a significant privacy problem.
Current architectures may attempt to address this problem by providing mechanisms that limit which software has access to the device's public key and which may ask the device to sign a message. However, these solutions tend to be severely limited in application, often solving the problem only for a small subset of the problem space.